Numerous tools have been developed to aid in network management involving capacity planning, fault management, network monitoring, and performance measurement. One example of such tools is the network analyzer.
In general, a “network analyzer” is a program that monitors and analyzes network traffic, detecting bottlenecks and problems. Using this information, a network manager can keep traffic flowing efficiently. A network analyzer may also be used to capture data being transmitted on a network. The term “network analyzer” may further be used to describe a program that analyzes data other than network traffic, or may also be used to classify packets into flows. For example, a database can be analyzed for certain kinds of duplication. One example of a network analyzer is the SNIFFER ANALYZER™ device manufactured by NETWORK ASSOCIATES, INC™.
One common task that a network analyzer often performs is the calculation of application response times. In particular, the time between a request to a server application and the fulfillment of the request by the application is measured. Often, network analyzers have different modes of operation (i.e. real-time mode, “expert” mode, etc.) for measuring application response times.
In a real-time mode, the network analyzer measures response times based purely on a response to the aforementioned requests by way of transport level acknowledgements. Unfortunately, these acknowledgements merely provide an indication that the request has been received by the transport layer of the server and not necessarily by the application. In other words, measuring only acknowledgements for response times tends to give skewed response times because it may not reflect that the request has been fulfilled. Thus, such real-time mode fails to provide an accurate indication of a true response time of an application.
In the expert mode, response time measurements are made “post capture.” In other words, the expert mode first collects network traffic information before measuring response times. Unfortunately, this does not provide real-time results, and is severely limited by many factors that make it somewhat useless during high link utilization. For example, the capture of network traffic information may become overloaded, resulting in a loss of data which, in turn, renders inaccurate calculations. Further, the expert mode is not scaleable.
In both cases, the response times are calculated on a “per-event” basis. Unfortunately, the foregoing modes do not provide any details on a “per conversation” basis, or information relating to upper layer transaction response times (i.e. application verbs, transactions, etc.).
There is thus a need for a technique of measuring response times for particular transactions or transaction types, between two network endpoints in real time. There is further a need to aggregate this collected information with minimum overhead. Still yet, there is a further need to accomplish this without capturing and storing packets for post analysis.